As improvements and development of integrated circuits result in miniaturization and complexity of the Integrated Circuits (IC) consideration has to be given to ensure that the ICs built in real hardware will function correctly. To avoid releasing products with errors that can lead to malfunctioning it is desirable to verify that the new device operates according to defined earlier functional specifications.
A standard method to provide such verification in the conventional technology is the one based on Bus Functional Model (BFM) approach. In this approach a synthesizable model of the IC, called Full Functional Model (FFM), is verified against the BFM that is a behavioural model of the same IC. FFM is also used to produce the IC itself. There are hardware simulators, known in the art (e.g. Verilog), that support such verification.
Another major application of BFM is using it to provide an early hardware/software integration and reduce the development time and debug the software even before the physical IC is ready. BFM can both generate and verify simulation vectors that are sent to and received from the simulated IC. In this approach it is verified how the software part works with other devices on the bus. The software communicates with other devices on the bus using the BFM that, in this case, is a layer between the software and the bus.
As mentioned earlier in the specification the Bus Functional Model (BFM) is a behavioural model, and is developed in Hardware Description Language (HDL) (one of the existing industry standard languages such as Verilog, VHDL, SystemC, etc.) that allows stimulating bus activity or an activity on any specified interface to IC, based upon given stimulus. A bus functional model typically interacts with an IC during a simulation by sending data to and receiving data from the IC. Stimuli are transferred to and from BFM using task based Application Program Interface (API) function calls. BFM can be used together with different simulation instruments. Usually BFM includes interface to bus functions as well as some functionality of the device that uses this interface.
BFM works as a bus interface unit. In the common approach it has two interfaces: bus pin interface and transaction task interface. Pin interface is used for communication with other bus devices according to the bus protocol. Transaction task interface is used for the execution of transactions that allow using special high level commands such as “READ” or “WRITE” which are translated into sequences of low-level signals in the pin interface. Such approach allows the model to generate different bus activities without execution of the whole program.
In methods known in the art the BFM code is developed according to three main inputs: IC Specification, HDL language, developers' experience. HDL language is taken as an instrument for creation of BFM through the analysis of the IC Specification applying the developers' experience in the area of modelling. There are no well-defined rules established for the interaction between these inputs. Therefore, each time BFM is created, the task of BFM design, the way of usage of IC Specification, and choice of the particular way of implementation is resolved individually according to the developer's team experience.
Results of such technique are several basic problems in the BFM development.
First, BFM structure is not formalized, thus the task of BFM development requires a deep knowledge on modelling and experience in BFM design.
Another big problem results form the fact that each time a BFM is being created, the architecture of it shall be developed again.
Yet another problem is that languages currently used for model development are not aimed for development of BFM as such and are not enough high-level. On the one hand they allow generating a wide range of different models (including BFMs) but on the other hand they are not very effective to produce BFMs in particular.
The above general problems lead to the following derivative problems of non-optimal code.
The code that is not strictly structured and not enough high-level, which is big and complex, potentially contains much more defects, and the efforts to locate these defects and resolve them consequently increase. The maintenance and modification of such code is also rather difficult.
Furthermore, not structured BFM code tends to be asynchronous. And one of the major problem of the asynchronous code is “signal racing”. The “signal racing” problem occurs in situations when at the same simulation time a certain data element is set in one process and is being read in the other process. This leads to the situation when it is not guaranteed that the reading process will get correct value of the data element (it can be set and then read and also vice versa). This problem cannot be exposed during testing. The code may work correctly on the tests but may occasionally fail sometime when these two events are rescheduled in the simulator for some reason. So the behaviour of the model becomes unpredictable.
As this kind of defects cannot be revealed by tests with certainty (it may be unrepeatable or even not detected at all) the only reliable way to find and resolve this problem is the analysis of the code by means of code inspection. But these method is very expensive and effort consuming, especially if the code is big and complex.
BFM HDL code is dependant on the specific of the particular source language and is very difficult to transfer to another source language.
Additionally the code that is complex and not strictly structured is very difficult to be reused.
In the U.S. Pat. No. 5,920,711 a method of automatic generation of models specified by frame protocols is disclosed. The method proposes to specify the model by a Frame State Machines using visual tools and then the model HDL code may be automatically generated from it. The problem of this approach is that not every protocol may be easily specified by Frame State Machine and thus this method is not applicable (or hardly applicable) for the whole range of BFMs.
Hence, considering the above problems, better method of BFM development is needed. The new method should make it less effort consuming and reduce BFM code size and complexity.